Dynamic Web Service Composition Based on Operation Flow Semantics

Dynamic Web service composition is a process of building a new value added service using available services to satisfy the requester’s complex functional need. In this paper we propose the broker based architecture for dynamic Web service composition. The broker plays a major role in effective and efficient discovery of Web services for the individual tasks of the complex need. The broker maintains flow knowledge for the composition, which stores the dependency among the Web service operations and their input, output parameters. For the given complex requirements, the broker first generates the abstract composition plan and discovers the possible candidate Web services to each task of the abstract composition plan. The abstract composition plan is further refined based on the Message Exchange Patterns (MEP), input and output parameters of the candidate Web services to produce refined composition plan involving Web service operations with preferable execution flow. The refined composition plan is then transferred to generic service provider to generate executable composition plan based on the requester’s input/output requirements & preferences. The proposed effective Web service discovery and composition mechanism is defined based on the concept of functional semantics and flow semantics of Web service operations. INTRODUCTION The success of Web service technology lies in the effective & efficient dynamic discovery and compositions of advertised Web services. A Web service is an interface, which describes a collection of operations that are network accessible through standardized XML messaging [1]. At present, the Web service architecture is based on the interactions between three roles i. e. service provider, service registry and service requester. The interactions among them involve publish, find and bind operations [1]. Web service discovery is the mechanism, which facilitates the requester, to gain an access to Web service descriptions that satisfy his functional needs. The dynamic composition process assembles the available services to build new service to satisfy the requester’s complex demand. UDDI [2] is the early initiative towards discovery, which facilitates both keyword and category based matching. The main drawback of such mechanism is that, it is too syntactic and provides no support for dynamic composition of Web services. There is a need to describe the Web services in a natural way to improve the effectiveness of the discovery and composition mechanism. The conceptual Web service architecture [1] involving service registry (UDDI) does not provide infrastructure or the mechanism for effective & efficient dynamic Web service discovery and composition. To enable effective and efficient dynamic Web service discovery and composition, the existing architecture has to be augmented by introducing new roles and new operations. A. Literature Survey and Brief review In literature, different architectures are proposed for dynamic Web service discovery and composition. We classify the architectures based on the storage of Web service information and processing component of discovery and composition as follows: agent based architectures, broker based architectures, peer-topeer architectures and hybrid architectures. In agent based Web service architectures [4], the service agents are used to initiate the request, terminate the request and to process the messages. In the broker based architectures [5] [6], the broker is used for the optimal selection of Web services for the composition plan towards dynamic integration of QoS-aware Web services with end-to-end QoS constraints. The peer-topeer composition architecture is an orchestration model which is defined based on the peer-to-peer interactions between software components hosted by the providers participating in the composition [7]. Such architectures are also capable of composing Web services across wide area networks with the service composition based on the interface idea integrated with Peer to Peer ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 2 technologies [8]. In hybrid architectures, along with service registry, other roles (for example third party provider in [9] and composition engine in [10]) are defined for the abstract composition plan generation and execution. A variety of techniques have been proposed in literature which integrates existing services based on several pieces of information. Most of the composition strategies are defined based on the output and input matching of available Web services [11]. Such composition mechanisms use chain [12], graph (tree) [13], vector [14] data structures for the dynamic composition of concrete services. The main problem with this approach is that, the repository search time is quite more for the matching of output parameters with the inputs. Also domain ontology has to be used for effective matchmaking. The requester’s constraints are useful to build composition involving concrete Web services [15]. The atomic or composite Web services are composed to satisfy the complex demand based on business rules or policy information [16]. The context (process/user) or view also plays a major role in effective Web service composition [17]. The goal [18], service behavior [19], user satisfaction and interaction patterns [20] guide the effective dynamic Web service composition. The Web service composition can be modeled in different ways. The Petri nets [21], Labeled behavior diagrams (LBD) [22], Mathematical model [23], UML Activity [24] and state chart diagrams [25], Workflow Model [26] and Finite automata [27] are the major modeling methods used to represent the composite Web service. In this paper, we propose a methodology to build an abstract composition plan which is defined based on the flow graph concept. The abstract composition plan (graph) is then refined by selecting suitable candidate Web services and their operations. The paper also proposes the broker based architecture for the dynamic Web service composition which facilitates the requester to discover the suitable Web service(s) for his simple or complex functional need. The rest of the paper is organized as follows. The next subsection gives definitions for the terminology used throughout the paper. In section 2, we present a model to describe the Web service operation functionality and flow. Section 3 presents the broker based architecture for the discovery and composition. Section 4 presents the Web service discovery and composition mechanism. In section 5, we discuss prototype implementation and experiment results. Section 6 draws the conclusions. B. Terminology Used in the Paper Here we present definitions of terms used throughout the discussion. Simple Request. A simple request for the Web service contains a single operation or functionality to be executed by the service provider. For example, reserve train ticket is a simple request. Complex Request. A complex request for the Web service contains a set of related or unrelated multiple operations (functionality) to be executed by the service provider. For example, arrange tour with operations like reserve flight ticket, reserve hotel room and book taxi is a complex request. Atomic or Primitive Web Service. The atomic Web service is a well defined network accessible application interface which is a collection of related operations implemented by single provider. Composite Web Service. A composite Web service is collection of operations/activities where each activity is offered or implemented by different service providers. The composite service provider may offer number of activities/operations by reusing the existing services available over the Web. Core Operation. A core operation of Web service is an important operation of Web service. A Web service may contain any number of core operations. For example, the travel service may contain core operations like reserve train ticket and cancel train ticket. Supplementary Operation. A supplementary operation is a Web service operation which provides support to the core operation. The supplementary operations indirectly add the value to the core services i.e. these operations support the execution of core operations. For example, the operation check train ticket availability is a supplementary operation. Abstract Operation. The functionality of an operation described in WSDL document of Web service during service advertisement. This represents a set of concrete operations supported by the advertised Web service. ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 3 Virtual Operation. A single, compact and complete description of functionally similar abstract operations is referred to as virtual operation. Web Service Composition Problem. Given a set of available Web services (atomic or composite), providing single or multiple operations (activities), create a new Web service by combining the available services (service operations) that realizes the complex service request of the requester. II. THE SEMANTIC MODEL FOR WEB SERVICE DESCRIPTION, DISCOVERY AND COMPOSITION The effective Web service discovery and composition enforces the service providers to follow the functional semantics and flow semantics during service advertisements. The service requesters also need to use the functional semantics while describing the service request. In this section, we briefly explain the concept of functional semantics and flow semantics for Web services. A. Functional Semantics for Web Service Operations The functional semantics approach [28] adopts the natural way of expressing the functionality of Web service operations i.e. abstract operations of Web services are expressed in terms of actions, objects, qualifiers and nouns. Thus functionality (OPDesc) of an abstract operation can be described in the following three formats. (i) OPDesc = {(Generic Action) (Qualifier)* (Domain Object) + (Domain Noun)} (ii) OPDesc = {(Specific Action) (Qualifier)* (Domain Object) + } (iii) OPDesc = {(Qualifier)* (Domain Object) + Action Noun} All abstract operation descriptions are preprocessed before mapping them to virtual operations [28]. The following rules guide the preprocessing of abstract operation description. Rule 1. If the action noun is present along with the generic action then the generic action is replaced by specific action which is related to the action noun and the action noun is eliminated from the description. Rule 2. If the action noun is found in the operation description with no generic or specific action then the specific action of the action noun is considered eliminating the action noun. As an illustration, consider the abstract operation description “prime number generation”. This description is transformed into “generate prime number” which can be considered as a virtual operation. B. Flow Semantics for Web Service Operations The Web service can be viewed as collection of interdependent or independent operations. For example, the travel Web service may offer its services though the following three interdependent operations namely (i) check train ticket availability (2) make train ticket reservation (iii) cancel train ticket. We define a graph structure called Operation Dependency Graph (ODG) which represents the possible order of execution of operations of a Web service. Operation Dependency Graph (ODG). Operation dependency graph is a directed acyclic graph with finite vertices which represent the number of operations of a Web service. A directed edge (u v) between any two vertices u and v indicate the possible order of execution such that, the activity v is executed after successful execution of activity u i.e. the activity v is dependent on activity u. We define two forms of activity dependencies called weak dependency and strong dependency. The weak dependency is found between any two supplementary operations or between supplementary and core operation. The strong dependency is found between any two core operations or between core and supplementary operation. As an illustration, consider the Web service “Tour Arrangement Service” involving five core operations. The possible order of execution of activities can be modeled using ODG as shown in Figure 1. The dotted lines in ODG represent the weak dependency and thick circles represent the core operations of Web service. The ODG of all published Web services are represented using flow knowledge as follows. Operation Predecessor List (OPL). Operation predecessor list of an operation OP is a sorted list containing operations for which OP is dependent on them i.e. list of operations which are predecessors of OP in the ODG. ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 4 Figure 1. Operation Dependency Graph (ODG) of Web Service Operation Dependency List (ODL). Operation dependency list is a sorted list with finite elements where each element contains two fields namely operation identifier and opl-link; where, opl-link is a pointer to OPL of an operation. Figure 2.b shows the snapshot of ODL after advertisement of Web services. The operations Op1 to Op10 of four Web services are found in the ODG (Figure 2.a) of published Web services. Figure 2. Operation Dependency List (ODL) of Published Web Services C. Extension of WSDL Document We extend the WSDL 2.0 [3] structure to publish the Web services with functional semantics and flow semantics as follows. We select the documentation element of the WSDL to insert the information which is necessary for effective service discovery and composition. We define a new tag called operationDesc to insert the functional semantics of all abstract operations present in the Web service. We also define flowDesc element to insert operation dependencies. The extended WSDL document with functional and flow semantics for the “train reservation service” is depicted in Figure 3. ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 5 Figure 3. Extended WSDL Document of Train Reservation Service III. THE BROKER BASED ARCHITECTURE FOR DYNAMIC WEB SERVICE DISCOVERY AND COMPOSITION We propose broker based architecture for dynamic Web service discovery and composition by introducing two new roles to the conceptual architecture [1] with a few new operations between different architectural roles. The architecture involves a total of five roles. They are Service provider, Service requester, Service composer (generic service provider), Service registry and the Broker. The register operation is defined between the provider and broker. The provider registers service specific information including WSDL to the broker for Web service publishing. The publish operation is defined between the broker and service registry which saves the service binding and WSDL details into service registry. The find service operation is defined between the service requester and broker to obtain candidate Web services for a service request. The execute composition operation is defined between the ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 6 broker and service composer in which the broker sends an abstract composition plan involving Web services and their operations. The monitor functional knowledge operation is defined between the generic service provider and broker in which the domain analyst monitors the functional knowledge updated by the service registrations. A variety of update operations are defined between internal components of the broker. Figure 4 presents the broker based architecture depicting various architectural roles and operations. Figure 4. The Broker based Architecture for Dynamic Web Service Discovery and Composition A. Architectural Roles and their Activities Service Provider. Service provider is a responsible and authentic business organization which registers its services with the broker. A provider is allowed to register multiple services into the service registry through the broker. On successful service registration, the broker returns the service key to the provider. Service Requester. Service requester is either a business organization or a person who intends to utilize the services published by the provider. The service requester has to submit the service request to the broker for the service discovery. Service registry. Service registry (e.g. UDDI) is a repository which stores the service deceptions including business details, service details and binding information. The service registry provides access to service information through interface operations. The service registry also saves the WSDL link of the published Web service. Generic Service Provider (Service Composer). Service composer is a business organization which executes the requester’s complex requirements if they are not satisfied by the available atomic or composite Web services. The service composer first generates the executable composition plan by refining the operation dependencies of abstract composition plan based on parameter constraints and then executes a set of Web service operations as defined by the composition flow. Broker. Broker is a middleware which is responsible for service registration, publishing, discovery and composition plan generation. The broker is designed with major five architectural components. They are Service publisher, Service discovery & composition plan generator, Service knowledge, functional knowledge and flow knowledge. ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 7 B. Broker Components and their functions Service knowledge component of the broker is interlinked data structure which stores the abstract details of service i.e. operations supported by the Web service and their input/output details (discussed in next sub-section). The functional knowledge is the structure which represents actions, action nouns, qualifiers and domain objects of service domains. The detailed functional knowledge structure is found in [28]. The flow knowledge is the structure which represents the dependency among various operations supported by numerous Web services (refer section II.B). Service publisher component reads the Web service description from the provider and updates the functional knowledge, flow knowledge and service knowledge accordingly. The service discovery and composition plan generator uses the functional knowledge to map the requested abstract operations into virtual operations present in service knowledge. If all the requested operations are found in the single Web service then the Web service key is returned to the requester. If there exists no single Web service which fulfills the requested operations then the composition plan generator uses the flow knowledge to build abstract composition plan consisting of requested operations, supplementary operations and candidate Web services. The refined composition plan is then transferred to the generic service provider for the execution. C. Extended Service Knowledge Structure For the effective Web service composition, we define additional data structures called Input List (IL), Output List (OL) and Parameter List (PL) as follows. 1. Input List (IL). Input list is a dynamic sorted array with finite elements. Each element has two fields namely ws-id and op-id where, ws-id is Web service identifier and op-id is operation identifier. This list is sorted based on the Web service identifier. 2. Output List (OL). Output list is a dynamic sorted array with finite elements. Each element has two fields namely ws-id and op-id where, ws-id is Web service identifier and op-id is operation identifier. 3. Parameter List (PL). Parameter list is a dynamic sorted array with finite elements. Each element has four fields namely paraid, para-name, input-link and output-link. para-id is unique identifier generated by the broker, para-name refers to operation parameter name, input-link refers to pointer to IL (Web service operations for which the parameter is input parameter) and outputlink is a pointer to OL (Web service operations for which the parameter is input parameter). Apart from these three interlinked structures, the service knowledge also consists of two more interlinked structures called Web Service List (WSL) and Service Operation Tree (SOT). The definitions of these structures are presented in [29]. D. Assumptions The proposed broker based architecture for efficient & effective Web service discovery and composition is designed based on the following assumptions. 1. The composite Web service provider has to advertise the individual activities of composite Web service as operations. 2. The provider of the Web service has to browse the functional knowledge before the service registration in order to use the existing functional knowledge or augment the functional knowledge with additional related action, object, noun and qualifier words. 3. Service provider has to use the formats of functional semantics [28] to describe the Web service operations. 4. While publishing operations on new domain object, the provider has to identify the object type. 5. The provider of the Web service has to supply related words for objects, actions, qualifiers, and nouns during Web service registrations to improve the effectiveness of discovery mechanism. 6. While describing the operation description the provider should provide the complete description (major domain objects along with subobjects) of the functionality. 7. The provider of the Web service has to precisely identify the core and supplementary operations. 8. The provider and requesters have to avoid the use of plurals of domain object and action. ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 8 9. The provider should describe the input and output parameters of operations with generic parameter concepts. 10. The requester has to understand the request format for fruitful discovery results. IV. WEB SERVICE DISCOVERY AND COMPOSITION MECHANISM In this section we describe the Web service discovery and composition mechanism designed for the broker based Web service architecture. A. Effective and Efficient Web Service Discovery The Web service discovery process for the simple or complex service request is described below. 1. The service request is preprocessed according to functional semantic rules to retrieve the functional requirement(s) of service request. 2. The action list, qualifier list (if required), object list and noun list (if required) of the functional knowledge are searched to get the corresponding identifiers. The non-availability of any identifier results in discovery failure. 3. After obtaining required identifier(s) from the functional knowledge, the operation patterns for each task of the service request are formed. After building the operation patterns, the patterns are searched in virtual operation list (VOL). If the pattern is found then the corresponding operation identifier is retrieved from the VOL otherwise, discovery failure is reported. 4. The abstract Web service information of all published Web services is searched by traversing SOT (Figure 5) for the requested operation identifier(s). The discovered Web services are stored against the requested operations. 5. The Web services found common in all requested operation (s) are selected as candidate Web services for the service discovery and are returned to the requester. 6. The absence of a common Web service for all requested operations triggers the composition mechanism which is presented in the next sub-section. B. Web Service Composition Mechanism The composition mechanism to generate abstract composition plan involving Web service operations for the complex service request is described as follows. 1. Initialize the ODG (adjacency list) as empty graph 2. For each requested operation (op-id) do the following. • Insert the op-id into ODG as a new node. • Search in ODL for the presence of op-id. If the op-id (say pi) is found with empty OPL then the operation becomes the independent operation. If some operations (pj) are found in OPL then do Step-3 3. For every operation (pj) in OPL of pi do the following • If pj is present in request then, include the edge (pj->pi) in the resulting ODG (adjacency list) of composition plan. Repeat step 3 for pj until pi is reached or empty OPL is found or already visited operation is encountered. • If the pj is not present in request and pj is supplementary operation then insert new node (pj) to ODG and insert the edge (pj->pi). Repeat step 3 for pj until pi is reached or empty OPL is found or already visited operation is encountered. • If pj is not present in request and pj is not supplementary operation and there exist predecessors pk and pm of pj, such that, pk is in request and pk->pm then, insert the edge (pk->pi). 4. The candidate Web services for all supplementary operations are now obtained by traversing SOT. As an illustration, consider the service request involving five operations {Op2, Op4, Op8, Op9, Op10} and four advertised Web services as in Figure 2. Table 1 shows the discovered Web services for the requested operations Op2, Op4, Op8, Op9, Op10 through the Web service discovery algorithm (Figure 5). ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 9 Figure 5. Discovering Web services from SOT & WSL TABLE 1. OPERATIONS AND DISCOVERED WEB SERVICES Operation Discovered Web services Op2 WS1, WS2, WS3, WS4 Op4 WS1, WS2, WS3, WS4 Op8 WS2, WS4 Op9 WS2, WS3, WS4 Op10 WS3, WS4 Observed that, no single Web service is found common to all requested operations. Thus the broker generates the abstract composition plan which is shown in figure 6. Figure 6. Discovering Web services from SOT and WSL ©2010 International Journal of Computer Applications (0975 8887) Volume 1 – No. 26 10 C. Refining Abstract Composition Plan The abstract composition plan is now refined in sequence based on the message exchange pattern (MEP) of Web service operations, core and supplementary operations, Input and Output parameters and quality of service (QoS) like reliability. 1) Plan Refinement based on the Message Exchange Pattern Let M+K be the nodes of abstract composition plan (M= number of requested core operations and K= number of supplementary operations explored), Let G be the ODG of abstract composition plan. Step-1. For each node (S) in G, perform Step-2. Step-2. For each directed edge from node S to node D (S→D)